Entry point for digital rights management data

ABSTRACT

Disclosed is a record carrier, in particular a recordable or rewritable optical disc, having a program memory area for storing administrative data, a lead in area, a program area for storing user data and a lead out area. In order to enable a drive to access digital rights management data which are stored in the program area, comprising e.g. usage rights and cryptographic keys, it is proposed that the record carrier further comprises:—a DRM pointer entry (ALP) comprising the entry point for said digital rights management data is stored in the program area after said digital rights management (DRM) data, —a drive-readable entry comprising an information allowing the drive to find said DRM pointer entry (ALP) and to access said digital rights management (DRM) data is stored in said program area or said program memory area.

The present invention relates to a record carrier having a programmemory area for storing administrative data, a lead in area, a programarea for storing user data and a lead out area. The present inventionrelates further to a method of accessing digital rights management datastored in the program area of such a record carrier, a method ofrecording digital rights management data on such a record carrier, acorresponding drive and recording device as well as to a computerprogram for implementing said methods.

According to adaption layer specifications for implementing a securitysystem for read-only and rewritable optical discs digital rightsmanagement data is located in the lead in of the disc volume. The entrypoint for the digital rights management (DRM) data is contained in a DRMpointer entry, in particular in an adaption layer parameter space (ALP).Therein the physical locations of all key locker duplicates are listed,the key locker being the structure that contains both the rights and thekeys to the protected data. For the read-only and rewritable access typediscs the DRM pointer, in particular the ALP, is located at an addressthat is more or less fixed relative to the beginning of the programarea. In these cases the DRM pointer entry can be easily found.

For a recordable (write once) access type optical disc DRM data can belocated anywhere in the program area, and the DRM pointer entry can belocated anywhere after the DRM data. Finding the DRM pointer entry on arecordable disc is thus not straight forward. Without additionalmeasures it would involve scanning the whole of the recorded programarea until the DRM pointer entry is found, which can take a lot of time.A complication is that the drive is responsible for writing the DRM dataand the DRM pointer entry. A simple file containing a reference to theDRM pointer entry is therefore not a solution to the problem as thedrive has no knowledge of files. It is possible to devise a mechanism bywhich the drive writes the DRM pointer entry and communicates thelocation to the application that subsequently writes it to a file.However, this remains a non-optimal solution as it is relativelycomplicated, involves additional communication between drive andapplication and is less secure. In addition, locating the file entrythat describes the DRM pointer entry file can in itself be atime-consuming process that could involve jumping across the programarea several times.

Another complication is that it is possible that a disc written usingthe recordable access type is finalized using a non-compliant drive. Ifthis occurs a problem that exists for an open session remains afterfinalization.

A related problem is how the drive can detect, at mount time, that adisc contains DRM data. This is useful because it offers the opportunityto retrieve the key locker pre-emptively. In case of a read-only orrewritable disc mounting the disc would start with scanning the lead into retrieve the session parameters that are stored in the Q subchannel.By choosing the standard location of the area that contains the DRMpointer entry as a starting point a drive can detect whether the disccontains DRM data at the same time.

It is therefore an object of the present invention to provide a recordcarrier which solves the above problems and, in particular, which allowsa drive to make use of file system structures without in-depthsknowledge of the file system itself. Further, corresponding methods ofaccessing or recording digital rights management data on a recordcarrier and corresponding devices shall be provided.

This object is achieved according to the present invention by a recordcarrier wherein

-   digital rights management data are stored in the program area,-   a DRM pointer entry comprising the entry point for said digital    rights management data is stored in the program area after said    digital rights management data and-   a drive-readable entry comprising an information allowing the drive    to find said DRM pointer entry and to access said digital rights    management data is stored in said program area or said program    memory area.

The present invention is based on the idea to introduce a drive-readableentry pointing to the DRM pointer entry in particular to the ALP, whichenables the drive to find the DRM pointer entry and, by using thatentry, to find and access the DRM data. That drive-readable entry mayeither be stored in the program area or the program memory area, wherebyboth implementations have to ensure that the entry can be read by thedrive. For this the drive can use a file system structure withoutactually knowing the file system. In that case even non-compliant orunaware implementations maintain the information.

It should be noted that the present invention is not restricted torecordable (write-once) CDs (CD-R), but can be applied to other opticaldiscs as well, like other access type CDs or DVDs, such as a recordableDVD (DVD-R) in which case the area for storing administrative data isreferred to as recording management area (RMA) instead of program memoryarea (PMA). Thus, the term “program memory area” used in thisapplication show include such a recording management area as well.

Preferred embodiments of the invention are defined in the dependantclaims.

According to the first preferred embodiment of the invention an ALPpointer entry is stored in the program memory area which eithercomprises the address of the DRM pointer entry or a reference to avirtual allocation table entry (VAT) pointing to said DRM pointer entry(ALP). In particular, the actual physical address of the DRM pointerentry or the sequence number or byte position of the virtual allocationtable entry that contains the ALP pointer entry is stored in the programmemory area. This solution is very robust. It is shielded from anyactivity of the application or file system driver. However, once thesession is finalized the program memory area is no longer in the commonmount path and the value stored in it will only be retrieved if thedrive is told explicitly, e. g. by the application, to retrieve thepointer from the program memory area. Therefore, compliant drives couldas a standard practise scan the program memory area but this wouldintroduce an undesirable delay in the mounting of non-compliant discs.

Storing the physical address of the DRM pointer entry is file systemindependent and will also work if UDF (universal disc format) which iscurrently used as standard file system, is not used as the actual filesystem. However, currently there is no alternative for UDF for thedescribed program domain, and the number of PMA entries that can be usedis currently limited to 100. This means that only at most 100 differentALP pointer entries can be stored in this way.

Storing the virtual allocation table entry that points to the DRMpointer entry is tied to UDF. Using the ALP pointer entry stored in theprogram memory area to enable the drive to make use of a file systemstructure, in particular the virtual allocation table, without knowinganything of the file system is one preferred option.

According to another embodiment of the invention a descriptor, inparticular an implementation use volume descriptor (IUVD), storing areference to a virtual allocation table entry (VAT) pointing to the DRMpointer entry is stored in the program area. The descriptor preferablyholds the sequence number of the virtual allocation table entry that isused or the byte position of the address in the sector holding thevirtual allocation table, in particular the logical address of the DRMpointer entry counted from the beginning of the partition or thephysical address of the DRM pointer entry. By this solution a compliantUDF file system implementation initialises the session. The advantage isthat the IUVD will remain in the common mount path even after anon-compliant drive has finalized the session.

One option to achieve an entry in the virtual allocation table pointingto the DRM pointer entry is to let the drive insert or create a virtualallocation table entry pointing to the DRM pointer entry. The danger ofthis solution is that, if a UDF repair utility is used, it will detectthat the thus created virtual allocation table entry does not point toan actual file and may remove it. The latter will not invalidate thedisc, but it will make mounting less efficient. Furthermore, theoccurrence of such an event is unlikely.

Determining which virtual allocation table entry points to the DRMpointer entry can be achieved in several ways. An option, as defined inclaim 7, is to include two entries in the virtual allocation table, oneidentifying that the next entry is the DRM pointer entry, e. g. becauseit contains a magic number outside the valid address range of the mediumit is recorded on, and another entry containing the actual DRM pointerentry.

According to still another preferred embodiment a file entry comprisinga pointer to said virtual allocation table entry, to said DRM pointerentry or to a file storing the address of such DRM pointer entry isstored in the program area. Preferably the file resides in virtual spaceonly if the file entry uses the VAT table entry pointer as the addressof the file. The first step is to define a file. Either the ALP itselfis called a file or a file is created that contains the address of theALP. The second step is to create a file entry that describes the filein the file system. This file entry contains of the file either avirtual address or a physical address. Within standard UDFimplementations for data usually a physical address is used. If avirtual address is used then the file resides in virtual space, which isnot common for data but useful here. The virtual address is a pointer toan entry in the VAT. In other words, the address recorded in the fileentry for that file is the VAT entry (sequence number) holding thephysical address of the actual file (the data).

This solution is robust against UDF repair utilities as the virtualallocation table entry still points to actual data and a file entrystill exists for that data, i. e. the data is in a file within the filesystem. The ALP pointer entry can thus be found using the file systemsince the DRM pointer entry is given a certain file name that isincluded in the file system.

A method of accessing digital rights management data according to thepresent invention comprises the steps of:

-   reading a drive-readable entry, which is stored in said program area    or said program memory area, comprising an information allowing the    drive to find said DRM pointer entry and to access said digital    rights management data, and-   using said information comprised in said drive-readable entry to    read said DRM pointer entry, which is stored in the program area    after said digital rights management data, comprising the entry    point for said digital rights management data,-   using said entry point comprised in said DRM pointer entry to access    said digital rights management data.

A method of recording digital rights management data according to thepresent invention comprises the steps of:

-   storing said digital rights management data in the program area,-   storing a DRM pointer entry in the program area after said digital    rights management data, said DRM pointer entry comprising the entry    point for said digital rights management data, and-   storing a drive-readable entry in said program area or said program    memory area, said drive-readable entry comprising an information    allowing the drive to find said DRM pointer entry and to access said    digital rights management data.

A drive according to the present invention comprises:

-   reading means for reading a drive-readable entry, which is stored in    said program area or said program memory area, comprising an    information allowing the drive to find said DRM pointer entry and to    access said digital rights management data, and-   evaluation means for evaluating said information comprised in said    drive-readable entry and transmitting it to said reading means, said    reading means being adapted to read said DRM pointer entry, which is    stored in the program area after said digital rights management    data, comprising the entry point for said digital rights management    data, said evaluation means being adapted for evaluating said entry    point comprised in said DRM pointer entry and transmitting it to    said reading means for accessing said digital rights management    data.

Further, the present invention relates to a recording device forrecording digital rights management data comprising recording means forsaid digital rights management data in the program area, for storing aDRM pointer entry in the program area after said digital rightsmanagement data, said DRM pointer entry comprising the entry point forsaid digital rights management data and for storing a drive-readableentry in said program area or said program memory area, saiddrive-readable entry comprising an information allowing the drive tofind said DRM pointer entry and to access said digital rights managementdata.

The present invention also relates to a computer program comprisingcomputer program code means for causing a computer to perform the stepsof the methods according to the invention when that computer program isrun on a computer.

The invention will now be explained in more detail with reference to thedrawings in which

FIG. 1 shows a block diagram of a data reproduction device,

FIG. 2 shows layouts of an empty and an initialised disc,

FIG. 3 illustrates the use of an ALP pointer entry,

FIG. 4 illustrates the addition of data using an ALP pointer entry,

FIG. 5 illustrates the use of an implementation use volume descriptor,

FIG. 6 illustrates the implementation use volume descriptor mechanism,

FIG. 7 illustrates the addition of data when using an implementation usevolume descriptor,

FIG. 8 illustrates the use of two virtual allocation table entries, and

FIG. 9 illustrates the use of a file entry.

FIG. 1 shows a block diagram of a reproduction device according to thepresent invention. To read user data from a disc 1 a reading unit 2 isprovided. However, part or all of the user data may be subject to usagerestrictions as defined in a digital rights management (DRM) systemagreed upon by content providers and consumers. This means that contentstored on the disc 1 may be encrypted, and the content has to bedecrypted before it can be replayed by the user. Therefore cryptographickeys can, for instance, be stored in a particular area on the disc.Further, usage rights can be stored on the disc 1, e. g. indicating if auser is allowed to make copies of the content. Such usage rights andkeys shall be referred to as DRM data in the following. To read such DRMdata a respective DRM reading unit 3 is provided. To find an access tothat DRM data one or more pointers have to be found and evaluated by anevaluation unit 4 before the DRM data can actually be read. The read DRMdata will then be used to control the output of user data, i. e. controlunit 5 will control the content reading unit 2, for instance prohibitthe output of data if a usage right prohibits the output or decrypt userdata before outputting it. Of course, other usage rights can becontained in that DRM data as well leading to a different control of theoutput of user data. The reading units 2, 3 and the evaluation unit 4can also be considered as a drive.

In particular for a recordable optical record carrier the DRM data canbe located anywhere in the program area, and the adaption layerparameter space (ALP) which is used as DRM pointer entry comprising theentry point for that DRM data is located anywhere after the DRM data. Itwill always be possible to find the ALP by scanning backwards startingfrom the last valid block on the disc. However, this procedure can bevery time-consuming. In the following, different measures shall beexplained for enabling a drive to access the DRM data stored in theprogram area of a disc.

FIG. 2 a shows a layout of an empty disc where the power calibrationarea (PCA) has been left out. From left to right reserved spacesprovided for the program memory area PMA, the lead in area, the programarea and the lead out area are shown.

FIG. 2 b shows the layout of an initialised disc which, in theparticular example, is unaware of a particular standard, e. g. a CD2standard or the Orange Book part II standard. A CD2 unawareinitialisation of a CD-R for sequential access means that there are noCD2 specific structures on disc and any host (drive, application) willrecognize the disc as being a standard (non-CD2) disc. It also meansthat CD2 content placed on this disc, e. g. by some form ofsuper-distribution, cannot be accessed for rendering until a CD2 awareapplication activates the content using a CD2 drive. As shown in FIG. 2b, in the PMA the location of the first (reserved) track and the second(UDF data) track are recorded in an initial entry EI. A section markedwith UDF holds all volume structures. Further, a virtual allocationtable VAT information control block ICB is provided after the UDFsection. A VAT is an UDF structure that provides address remapping. Inthis case the VAT ICB also hold the VAT itself.

If it is assumed that the UDF implementation used is CD2 unaware, thenno CD2 specific structures are included in the initialisation. At thattime the system cannot by itself determine if the CD will be used forstoring CD2 content in the future and, therefore, a CD2 PMA entry cannotbe included in the initialisation procedure preemptively. If the UDFimplementation used is CD2 aware then the CD2 implementation use volumedescriptor (IUVD) can be recorded as shown in FIG. 2 c. Apart from beingthe CD2 marker in case of an otherwise generic disc, the IUVD providesthe location of the ALP address in the VAT. This location can be fixed,e. g. being the first entry, if the VAT is guaranteed to bedeterministic when the ALP is added, i. e. if there are no previoussessions. According to a first embodiment of the invention an ALPpointer stored in the PMA shall be used. If CD2 data shall be recordedon a non-CD2 disc the drive needs to be a CD2 drive. The UDFimplementation can be generic and the application is irrelevant.

FIG. 3 a shows a storage layout after a CD2 unaware UDF implementationhas added CD2 data. Just prior to physically ejecting a disc or upondetection of the writing of the VAT the key lockers KL and the ALP arewritten and the VAT is reproduced as shown in FIG. 3 b. The key lockeris a container for the usage rights and asset keys, i. e. the DRM datawhich have to be accessed by the drive of the reproduction device beforethe CD2 data can be reproduced. The ALP is a structure that contains theentry point for said key lockers KL, i. e. it enables to find thelocation of the DRM data KL. In order to allow a drive to find the ALPan ALP pointer entry E2 containing an ALP pointer is recorded in thePMA. In this case the drive needs to be a CD2 drive. It should be notedthat “UDF” indicates non-CD2 data and “CD2 ” indicates CD2 data.

Any subsequent addition of data is independent from the history of thedisc. FIG. 4 a is identical to FIG. 3 c and shows the final state afteradding the ALP pointer entry E2. When adding non-CD2 data, as shown inFIG. 4 b, these special measures are taken because if not-CD2 data isadded, as shown in FIG. 4 b, a link to the ALP, i. e. the ALP pointerentry E2, will be preserved. Adding CD2 data, as shown in FIG. 4 c, isonly possible in a CD2 drive. In this case the KL, ALP and VAT ICB arere-written. Further the ALP pointer entry E2 has to be renewed into ALPpointer entry E3.

It should be noted that the maximum number of entries in the PMA limitsthe number of times the ALP pointer entry can be updated (in practice toabout 100). The described scheme is very robust and requires no driveror application support. However, the translation and alteration of theVAT is a sensitive issue. The VAT ICB is the last structure on the discit is a pointer to the VAT. If the size of the VAT and the VAT ICBcombined is smaller than the logical block size (2 KB on CD) then theVAT ICB contains the VAT itself.

The latter is almost always the case and in case of CD2 it is required.While in the above described embodiment the ALP pointer entry stored inthe PMA comprises a reference to the ALP, in particular the address ofthe ALP, in a slightly different embodiment the ALP pointer entry maycomprise a reference to the VAT entry which points to that ALP. Bothembodiments lead to the same results, i. e. allow a drive which is ableto read the ALP pointer entry to finally find the DRM data.

According to another embodiment the above-mentioned implementation usevolume descriptor IUVD shall be used for that purpose. The CD2 specificIUVD is optional.

The use of the IUVD requires the initialising UDF implementation to beCD2 aware. The scheme that the IUVD is part of also requires theinsertion of the physical block number (PBN) of the ALP in the VAT. TheIUVD indicates which VAT entry identifies the location of the ALP.Although generic UDF implementations will preserve the link, it will notbe updated. Hence, if the ALP is rewritten using a CD2 unaware UDFimplementation the value of the PBN of the ALP in the VAT will not becorrect unless a special procedure is in place that allows the drive toupdate the physical address of the ALP in the VAT. Failing to guaranteethat means that the value recorded in the PMA must always takeprecedence over the value recorded in the VAT. It should be noted thatthis influences the procedure for the localization of the ALP only. Inany case there is only one valid ALP.

FIG. 5 a shows the layout of the disc structure where an IUVD, an UDFdata entry and a VAT ICB are recorded in the program area. The IUVDholds the number of the entry in the VAT that identifies the physicaladdress of the ALP pointer, indicated by the arrow. If, as shown in FIG.5 b, a CD2 unaware UDF implementation adds CD2 data the VAT ICB isrewritten. Just prior to physical ejecting a disc or upon detection ofthe writing of the VAT the KL and ALP are written as shown in FIG. 5 c.The VAT is copied and the PBN of the ALP is inserted in the VAT at theappropriate position.

This is illustrated in FIG. 6 showing on top the layout of the datastructure of the disc as shown in FIG. 5 c after another UDF data entryhas been made leading to a shift of the VAT ICB. Shown is the IUVDstructure comprising an entry “ALP pointer” the content of which is “n”.That entry “n” indicates that VAT entry “n” of the shown VAT structureholds the physical address of the ALP.

Any subsequent addition of data is independent from the history of thedisc. If non-CD2 data is added the ALP VAT entry is preserved. If CD2data is added a CD2 drive is required. This is illustrated in FIG. 7.FIG. 7 a shows a layout as shown in FIG. 5 c. When adding non-CD2 dataas shown in FIG. 7 b no special measures are needed since the link tothe ALP will be preserved in the shifted VAT ICB. Adding CD2 data, asshown in FIG. 7 c, is only possible in a CD2 drive. The KL, ALP and VATICB are then to be rewritten as shown.

According to still another embodiment which shall be illustrated withreference to FIG. 8 two entries are provided in the VAT. The first entry(VAT entry n) identifies that the next entry (VAT entry n+1) is the ALPpointer, e. g. because it contains a magic number. The subsequent entry(VAT entry n+1) contains the actual ALP pointer, in particular comprisesthe address of the ALP.

In still another embodiment of the invention an entry in the VATpointing to the ALP is achieved by creating a file entry in the virtualpartition. The first step is to define a file. Either the ALP itself iscalled a file or a file that contains the address of the ALP is created.The second step is to create a file entry FE that describes the file inthe file system. This FE contains of the file either a virtual addressor a physical address. Within standard UDF implementations for datausually a physical address is used. If a virtual address is used thenthe file resides in virtual space, which is not common for data butuseful here. The virtual address is a pointer to an entry in the VAT. Inother words, the address recorded in the FE for that file is the VATentry (sequence number) holding the physical address of the actual file(the data).

This is illustrated in FIG. 9. FIG. 9 a shows the layout without theproposed file entry. The VAT points to the ALP which points to the KL.In FIG. 9 b a file entry has been inserted and stored in the programarea. That file entry FE comprises a pointer to the VAT. This solutionis robust against UDF repair utilities as the VAT entry still points toactual data and a file entry FE still exists for that data, i. e. thedata is in a file within the file system. The ALP pointer can thus befound using a file system since the ALP is given a certain file namethat is included in the file system.

According to a variation it is possible to let the application create afile with a virtual address. The virtual address as stored in the VATwill point to either a file containing the physical address of the ALPor to the physical location of the ALP directly. The actual finalizationprocess for the embodiments as described above will be initiated from anapplication. This application can be CD2 aware or not. The drive thatperforms the finalization can also be either CD2 aware or not.

Another issue is how the drive determines when to write the key lockerarea (KLA) comprising the KL and ALP. Ideally, this is done just priorto the writing of the VAT before the disc is ejected.

However, the drive has no way of knowing when the VAT is written. Itcreates too much overhead to inspect each block to determine if it mightbe the VAT. The drive cannot rely on the application to tell it when theVAT is written because the application itself does not know.Furthermore, the VAT is not only written if the disc is to be ejected,the KLA ideally is.

A feasible solution is to detect the eject command. Any stable andreliable UDF implementation will write the VAT before it releases thedisc for ejection. Hence, if the drive knows it needs to write the KLAto a disc with a sequential access type and the UDF driver has releasedthe disc for ejection, the drive can safely assume that the VAT has beenwritten and that it will be the last valid block on disc. Another optionis to let the application give a command to the drive telling it towrite the KLA.

According to the present invention the drive is able to access thedigital rights management data which are stored in the program area byusing a file system level structure without actually knowing the filesystem. The advantage is that even non-compliant or unawareimplementations maintain the information.

1. Record carrier having a program memory area (PMA) for storingadministrative data, a lead in area, a program area for storing userdata and a lead out area, wherein digital rights management data arestored in the program area, a DRM pointer entry (ALP) comprising theentry point for said digital rights management data is stored in theprogram area after said digital rights management (DRM) data, and adrive-readable entry (E2, IUVD, FE) comprising an information allowingthe drive to find said DRM pointer entry (ALP) and to access saiddigital rights management (DRM) data is stored in said program area orsaid program memory area.
 2. Record carrier as claimed in claim 1,wherein an ALP pointer entry (E2) comprising the address of said DRMpointer entry (ALP) is stored in the program memory area (PMA). 3.Record carrier as claimed in claim 1, wherein an ALP pointer entry (E2)comprising a reference to a virtual allocation table entry (VAT)pointing to said DRM pointer entry (ALP) is stored in the program memoryarea (PMA).
 4. Record carrier as claimed in claim 1, wherein adescriptor, in particular an implementation use volume descriptor(IUVD), storing a reference to a virtual allocation table entry (VAT)pointing to said DRM pointer entry (ALP) is stored in the program area.5. Record carrier as claimed in claim 3, wherein said reference to saidvirtual allocation table entry (VAT) comprises the sequence number ofsaid virtual allocation table entry (VAT).
 6. Record carrier as claimedin claim 3, wherein said reference to said virtual allocation tableentry (VAT) comprises the physical address of said virtual allocationtable entry (VAT) within the sector of the program area storing saidvirtual allocation table entry (VAT).
 7. Record carrier as claimed inclaim 1, wherein an ALP pointer entry (E2) is stored in the programmemory area (PMA), said ALP pointer entry (E2) comprising a firstvirtual allocation table entry comprising a pointer to said DRM pointerentry (ALP) and a second virtual allocation table entry (VAT), inparticular located just before said first entry, indicating that saidfirst entry comprises said pointer to said DRM pointer entry (ALP). 8.Record carrier as claimed in claim 1, wherein a file containing said DRMpointer entry (ALP) or a pointer to said DRM pointer entry (ALP) and afile entry (FE) describing said file in the file system are stored inthe program area.
 9. A method of accessing digital rights managementdata stored in the program area of a record carrier as claimed in claim1, comprising the steps of: reading a drive-readable entry (E2, IUVD,FE), which is stored in said program area or said program memory area,comprising an information allowing the drive to find said DRM pointerentry (ALP) and to access said digital rights management (DRM) data,using said information comprised in said drive-readable entry to readsaid DRM pointer entry (ALP), which is stored in the program area aftersaid digital rights management (DRM) data, comprising the entry pointfor said digital rights management data, and using said entry pointcomprised in said DRM pointer entry (ALP) to access said digital rightsmanagement data.
 10. A method of recording digital rights managementdata on a record carrier as claimed in claim 1, comprising the steps of:storing said digital rights management data in the program area, storinga DRM pointer entry (ALP) in the program area after said digital rightsmanagement (DRM) data, said DRM pointer entry (ALP) comprising the entrypoint for said digital rights management data, and storing adrive-readable entry (E2, IUVD, FE) in said program area or said programmemory area, said drive-readable entry comprising an informationallowing the drive to find said DRM pointer entry (ALP) and to accesssaid digital rights management (DRM) data.
 11. Drive for accessingdigital rights management data stored in the program area of a recordcarrier as claimed in claim 1, comprising: reading means for reading adrive-readable entry (E2, IUVD, FE), which is stored in said programarea or said program memory area, comprising an information allowing thedrive to find said DRM pointer entry (ALP) and to access said digitalrights management (DRM) data, and evaluation means for evaluating saidinformation comprised in said drive-readable entry and transmitting itto said reading means, said reading means being adapted to read said DRMpointer entry (ALP), which is stored in the program area after saiddigital rights management (DRM) data, comprising the entry point forsaid digital rights management data, said evaluation means being adaptedfor evaluating said entry point comprised in said DRM pointer entry(ALP) and transmitting it to said reading means for accessing saiddigital rights management data.
 12. Recording device for recordingdigital rights management data on a record carrier as claimed in claim1, comprising recording means for storing said digital rights managementdata in the program area, for storing a DRM pointer entry (ALP) in theprogram area after said digital rights management (DRM) data, said DRMpointer entry (ALP) comprising the entry point for said digital rightsmanagement data and for storing a drive-readable entry (E2, IUVD, FE) insaid program area or said program memory area, said drive-readable entrycomprising an information allowing the drive to find said DRM pointerentry (ALP) and to access said digital rights management (DRM) data. 13.Computer program comprising computer program code means for causing acomputer to perform the steps of the method as claimed in claim 9 whensaid computer program is run on a computer.